Mtc key management for key derivation at both ue and network

ABSTRACT

There is provided a new IWF SMC procedure for establishing security association between an MTC UE ( 10 ) and an MTC-IWF ( 20 ). The MTC-IWF ( 20 ) sends to the UE ( 10 ) at least an algorithm identifier which instructs the UE ( 10 ) to select one of algorithms for deriving a root key (K_iwf). The UE ( 10 ) derives the root key (K_iwf) in accordance with the selected algorithm, and derives at least a subkey for checking the integrity of messages transferred between the UE ( 10 ) and the MTC-IWF ( 20 ) by using the derived root key (K_iwf). The UE ( 10 ) protects uplink messages transmitted to the MTC-IWF ( 20 ) with the derived subkey. The MTC-IWF ( 20 ) protects downlink messages transmitted to the UE ( 10 ) with the same subkey derived at a core network.

TECHNICAL FIELD

The present invention relates to key management in MTC (Machine-TypeCommunication) system, in particular to a technique to derive a key atboth of a UE (User Equipment) and a network.

BACKGROUND ART

As disclosed in NPL 1, the security over the interface between an MTCdevice and an MTC-IVVF (MTC Inter-Working Function) should be studied.

Note that the MTC device is a UE equipped for MTC, which will besometimes referred to as “MTC UE” or “UE” in the following explanation.

CITATION LIST Non Patent Literature

NPL 1: 3GPP TR 33.868, “Security aspects of Machine-Type and otherMobile Data Applications Communications Enhancements; (Release 12)”,V0.10.0, 2012-09

NPL 2: 3GPP TS 33.401, “3GPP System Architecture Evolution (SAE);Security architecture (Release 12)”, V12.5.1, 2012-10.

SUMMARY OF INVENTION of Invention Technical Problem

However, in 3GPP (3rd Generation Partnership Project), the study has notbeen fulfilled. Therefore, secure communication solution is requiredbetween an MTC device and an MTC-IWF.

Accordingly, an exemplary object of the present invention is to ensuresecure communication between an MTC device and an MTC-IWF.

Solution to Problem

In order to achieve the above-mentioned object, this invention dealswith the following issues: Deriving the same root key at both UE andnetwork side.

In this invention, there is proposed that network and UE derive the rootkey K_iwf separately. There is no key sent between them. Key derivationparameters can be either sent from network to UE or from UE to network.Inside the core network, the key derivation parameters can be sent fromHSS (Home Subscriber Server) to MTC-IWF and MME (Mobility ManagementEntity), or from MTC-IWF to HSS or MME. The derivation algorithms areavailable in the UE and the network node. Network indicates UE whichalgorithm should be used for root key derivation by using an algorithmidentifier.

There is also proposed a new IWF Security Mode Command (SMC) procedurefor the security association establishment between UE and MTC-IWF.

A communication system according to a first aspect of the presentinvention includes: an MTC-IWF; and a UE. The MTC-IWF stores a masterkey, derives subkeys for confidentiality and integrity protection, andinforms the UE about an algorithm for key derivation. The UE derives, byusing the algorithm, the master key and the subkeys such that the UEshares the same master key and the same subkeys with the MTC-IWF.Security association is established between the UE and the MTC-IWF byusing the shared master key and subkeys.

An MTC-IWF according to a second aspect of the present invention isconfigured to store a master key, derive subkeys for confidentiality andintegrity protection, and inform a UE about an algorithm for keyderivation to cause the UE to derive the master key and the subkeys suchthat the UE shares the same master key and the same subkeys with theMTC-IWF. Security association is established between the UE and theMTC-IWF by using the shared master key and subkeys.

A UE according to a third aspect of the present invention is configuredto derive, by using an algorithm for key derivation informed from anMTC-IWF, a master key and subkeys for confidentiality and integrityprotection such that the UE shares the master key and the subkeys withthe MTC-IWF. Security association is established between the UE and theMTC-IWF by using the shared master key and subkeys.

An HSS according to a fourth aspect of the present invention isconfigured to derive a master key, and to send the master key to anMTC-IWF. The master key is shared between the MTC-IWF and a UE, and usedfor establishing security association between the MTC-IWF and the UE.

An MME according to a fifth aspect of the present invention isconfigured to carry, to a UE, a NAS SMC message that includes an IWF SMCmessage for informing the UE about an algorithm for key derivation. Thealgorithm is used for the UE and an MTC-IWF to share a master key andsubkeys for confidentiality and integrity protection, and securityassociation is established between the UE and the MTC-IWF by using theshared master key and subkeys.

A method according to a sixth aspect of the present invention provides amethod of securing MTC communication. This method includes: storing, byan MTC-IWF, a master key; deriving, by the MTC-IWF, subkeys forconfidentiality and integrity protection; informing, by the MTC-IWF, aUE about an algorithm for key derivation; and deriving, by the UE usingthe algorithm, the master key and the subkeys such that the UE sharesthe same master key and the same subkeys with the MTC-IWF. Securityassociation is established between the UE and the MTC-IWF by using theshared master key and subkeys.

Advantageous Effects of Invention

According to the present invention, it is possible to solve theabove-mentioned problems, and thus to ensure secure communicationbetween an MTC device and an MTC-IWF.

BRIEF DESCRIPTION OF DRAWINGS

FIG. 1 is a block diagram showing a configuration example of acommunication system according to an exemplary embodiment of the presentinvention.

FIG. 2 is a sequence diagram showing one example of IWF SMC procedure inthe communication system according to the exemplary embodiment.

FIG. 3 is a sequence diagram showing another example of the IWF SMCprocedure in a case where IWF SMC is carried in NAS SMC.

FIG. 4 is a sequence diagram showing an example of root key derivationat both UE and network in a case where communication is triggered by anSCS.

FIG. 5 is a block diagram showing a configuration example of an MTCdevice according to the exemplary embodiment.

FIG. 6 is a block diagram showing a configuration example of a networknode according to the exemplary embodiment.

DESCRIPTION OF EMBODIMENTS

Hereinafter, an exemplary embodiment of the present invention will bedescribed with the accompany drawings.

As shown in FIG. 1, a communication system according to this exemplaryembodiment includes a core network (3GPP network), and one or more MTCUEs 10 which are UEs equipped for MTC and connect to the core networkthrough a RAN (Radio Access Network). While the illustration is omitted,the RAN is formed by a plurality of base stations (i.e., eNBs (evolvedNode Bs)).

The MTC UE 10 attaches to the core network. The MTC UE 10 can host oneor multiple MTC Applications. The corresponding MTC Applications in theexternal network are hosted on an SCS (Service Capability Server) 50.The SCS 50 connects to the core network to communicate with the MTC UE10.

Further, the core network includes an MTC-IWF 20 as one of its networknodes. The MTC-IWF 20 serves as a gateway to the core network for theSCS 50. The MTC-IWF 20 relays messages between the MTC UE 10 and the SCS50. The core network includes, as other network nodes, an HSS (HomeSubscriber Server) 40, an MME, an SGSN (Serving GPRS (General PacketRadio Service) Support Node), an MSC (Mobile Switching Centre) and thelike. In the following description, the MME and the SGSN are sometimesreferred to as “MME/SGSN”, and collectively or individually denoted bythe symbol 30. Communication between the MTC UE 10 and the MTC-IWF 20 isconducted through the MME/SGSN 30 (or the MSC).

Next, operation examples of this exemplary embodiment will be describedin detail with reference to FIGS. 2 to 4.

1. IWF SMC Procedure

FIG. 2 shows IWF SMC procedure using SAE/LTE (Long Term Evolution) NAS(Non Access Stratum) SMC mechanism for establishing security associationbetween UE 10 and MTC-IWF 20. This procedure will be described below.

Assume that MTC-IWF 20 has either received or derived the root key K_iwfand has derived subkeys. Note that the root key K_iwf is used forderiving the subkeys. The subkeys include at least an integrity key forchecking the integrity of messages transferred between the MTC UE 10 andthe MTC-IWF 20 (hereinafter, this key will be referred to as “integritysubkey”). The subkeys may also include a confidentiality key forencrypting and decrypting messages transferred between the MTC UE 10 andthe MTC-IWF 20.

S11: MTC-IWF 20 sends IWF SMC message to UE 10, with key derivationparameters (optional) and algorithm ID. The IWF SMC message is protectedby the integrity subkey. Integrity protection at downlink is started.

S12: UE 10 derives K_iwf and subkeys, by using the key derivationparameters and algorithm sent from MTC-IWF 20.

S13: UE 10 verifies the received IWF SMC message with the derivedintegrity subkey. Integrity protection at uplink is started. UE 10 sendsIWF SMC Reject message if the verification fails.

S14: If the integrity verification is successful, UE 10 sends IWF SMCComplete message to MTC-IWF 20 with integrity protection by using theintegrity subkey that UE 10 has derived. Uplink integrity protection isstarted.

S15: MTC-IWF 20 verifies the IWF SMC Complete message with integritysubkey it has derived.

S16: If the verification at Step S15 is successful, the securityassociation is established between UE 10 and MTC-IWF 20 and they canstart secure communication.

Meanwhile, as shown in FIG. 3, IWF SMC messages can also be carried inNAS SMC procedure.

S21: MTC-IWF 20 sends integrity protected IWF SMC message (same as StepS11 in FIG. 2) or the necessary parameters for UE 10 to perform keyderivation, with UE ID to MME 30.

S22: MME 30 carries the IWF SMC message with NAS SMC message and sendsit to UE 10.

S23: UE 10 performs NAS integrity verification.

S24: If NAS integrity verification fails, UE 10 sends NAS SMC Rejectmessage carrying IWF SMC Reject message to MME 30. MME 30 forwards theIWF SMC Reject message to MTC-IWF 20.

S25: If NAS integrity verification is succeed, UE 10 derives K_iwf andsubkeys.

S26: UE 10 performs integrity verification on the IWF SMC, if the IWFSMC message was sent at Step S21 with integrity protection. Theintegrity verification is by using the integrity subkey derived by UE10.

S27: UE 10 sends the NAS SMC Complete carrying IWF SMC Complete to MME30. The IWF SMC Complete message can be integrity protected.

Or UE 10 sends IWF SMC Reject message carried in NAS SMC Complete, ifthe verification at Step S26 fails.

S28: MME 30 forwards the IWF SMC Complete or IWF SMC Reject message toMTC-IWF 20.

S29: MTC-IWF 20 performs integrity verification on the IWF SMC Completemessage, if it was integrity protected.

S30: Security association is established between UE 10 and MTC-IWF 20and they can start secure communication. If MTC-IWF 20 received IWF SMCComplete, and integrity verification is passed at Step S29 (when it iscarried).

In this procedure, the integrity protection for IWF SMC message is byintegrity subkey, NAS SMC message protection and verification followsthe requirement in NPL 2.

2. Root Key Derivation At Both Network and UE

The initial key derivation at both sides of the UE and the core networkcan be triggered by:

-   -   Attaching of a MTC capable UE to the network where the UE does        not have K_iwf yet, and network verifies it is a MTC UE;    -   First time there is a trigger need to be delivered to UE and no        security association exists between the UE and MTC-IWF.

In this exemplary embodiment, take as an example a case wherecommunication is initiated by trigger from SCS 50. The details are shownin FIG. 4.

S31: Assume that security between HSS 40 and MTC-IWF 20 has beenestablished.

S32: SCS 50 sends MTC device trigger message to MTC-IWF 20, includingtarget UE ID.

S33: MTC-IWF 20 sends Subscriber Information Request message to HSS 40with msg type=trigger and UE ID. The msg type is to indicate HSS 40 thatthe request from SCS 50 is trigger.

S34: Mutual authentication with UE 10 is carried if UE 10 has not beenauthenticated yet.

S35: As an option, UE 10 can send some key derivation parameters tonetwork in NAS message.

In a case where MTC-IWF 20 derives K_iwf, the following Steps S36 to S38are performed.

S36: If MTC-IWF 20 does not have the key derivation parameters itself,HSS 40 can send them to MTC-IWF 20 in Subscriber Information Responsemessage.

S37: MTC-IWF 20 derives K_iwf and subkeys accordingly.

S38: IWF SMC procedure is carried, either as an independent procedure asshown in

FIG. 2 or embedded in NAS SMS procedure as shown in FIG. 3.

Alternatively, in a case where HSS 40 derives K_iwf, the following StepsS46 to S48 are performed.

S46: HSS 40 derives the K_iwf. If MTC-IWF 20 has the key derivationparameters, it can send it to HSS 40 at Step S33.

S47: HSS 40 sends K_iwf to MTC-IWF 20 in Subscriber Information Responsemessage.

S48: MTC-IWF 20 stores K_iwf and derives subkeys.

S49: IWF SMC procedure is carried, either as an independent procedure orembedded in NAS SMS procedure.

Alternatively, in a case where MME 30 derives K_iwf, the following StepsS56 to S60 are performed.

S56: HSS 40 sends the key derivation parameters, algorithm ID to MME 30in Authentication data response or Insert Subscriber Data.

S57: MME 30 derives K_iwf.

S58: MME 30 sends the derived K_iwf to MTC-IWF 20, in any one of thefollowing two ways, for example.

One way is that MME 30 sends K_iwf in a new message to HSS 40, then HSS40 sends it to MTC-IWF 20 in a new message called Update SubscriberInformation message.

The other way is that MME 30 directly sends K_iwf over interface T5 in anew message or in a Report message to MTC-IWF 20.

S59: MTC-IWF 20 will store the K_iwf and derives the subkeys.

S60: IWF SMC procedure is carried, either as an independent procedure orembedded in NAS SMS procedure.

The IWF SMC procedure is the same for the case where UE 10 initiatescommunication. At Step S36 and Step S47, the above-mentioned UpdateSubscriber Information can be used for HSS 40 to send key derivationparameter or K_iwf.

Next, configuration examples of the MTC UE 10 and the MTC-IWF 20according to this exemplary embodiment will be described with referenceto FIGS. 5 and 6. Note that in the following explanation, there will bedescribed only elements which are specific to this exemplary embodiment.However, it will be understood that the MTC UE 10 and the MTC-IWF 20also include elements for functioning as typical MTC UE and MTC-IWF,respectively.

As shown in FIG. 5, the MTC UE 10 includes a negotiation unit 11 whichnegotiates with the MTC-IWF 20 to establish the security associationwith the MTC UE 10 and the MTC-IWF 20 as shown in FIGS. 2 to 4. Thenegotiation unit 11 can transfer messages for the negotiation to theMTC-IWF 20 thorough the MME 30 as shown in FIG. 3. The negotiation unit11 can send the key derivation parameters to the core network as shownat Step S35 in FIG. 4. The negotiation unit 11 can receive the algorithmID from the MTC-IWF 20 as shown at Step S11 in FIG. 2. At the same StepS11, the negotiation unit 11 can further receive the key derivationparameters from the MTC-IWF 20. The negotiation unit 11 can derive theroot key K_iwf and subkeys as shown at Step S12 in FIG. 2, and canverify the IWF SMC message received from the MTC-IWF 20 with the derivedintegrity subkey as shown at Step S13. As shown at Step S14, uponsucceeding in the verification, the negotiation unit 11 protects the IWFSMC Complete message with the integrity subkey, and sends the protectedIWF SMC Complete message to the MTC-IWF 20. Upon failing in theverification, the negotiation unit 11 sends the IWF SMC Reject messageto the MTC-IWF 20. This negotiation unit 11 can be configured by, forexample, a transceiver which conducts communication with the MTC-IWF 20through the MME 30 and the RAN, a controller such as a CPU (CentralProcessing Unit) which controls this transceiver.

As shown in FIG. 6, the MTC-IWF 20 includes a negotiation unit 21 whichnegotiates with the MTC UE 10 to establish the security association withthe MTC UE 10 and the MTC-IWF 20 as shown in FIGS. 2 to 4. Thenegotiation unit 21 can transfer messages for the negotiation to the MTCUE 10 thorough the MME 30 as shown in FIG. 3. The negotiation unit 21can send the algorithm ID to the MTC UE 10 as shown at Step S11 in FIG.2. At the same Step S11, the negotiation unit 21 can further send thekey derivation parameters to the MTC UE 10. The negotiation unit 21 canprotect the IWF SMC message with the integrity subkey. The negotiationunit 21 can verify the IWF SMC Complete message received from the MTC UE10 with the integrity subkey as shown at Step S15 in FIG. 2. Thisnegotiation unit 21 can be configured by, for example, a transceiverwhich conducts communication with the MTC UE 10 through the MME 30 andthe RAN, a controller such as a CPU which controls this transceiver.

Based on the above description, solutions will be proposed to 3GPP TR33.868 as follows.

1. Discussion

In MTC device triggering, application security between SCS and UE canprotect trigger with confidentiality and integrity protection fromeavesdropping or alteration.

However, since the communication for trigger delivery happens via mobilenetwork, when we consider the security issues that the (unauthorized)triggering from SCS can bring, we also need to study the attacks to thenetwork and the UEs attached to it. As described in threats section ofTR 33.868, section 5.1.2, the attacks can cause UE power consumption,DoS attack to network, waste of network resources, overload NAS, andprivacy issues. Since application security cannot solve these issues,security at transport and network layer should be considered.

In the existing system at NAS layer, MME and UE can establish NASsecurity. The trigger forwarded from MME to UE can have NAS securityprotection but MME was not designed for MTC purposed such that it doesnot perform any verification of SCS or the trigger from it. MME forwardsany trigger it receives, which makes NAS security insufficient.Meanwhile, hop-by-hop security among MTC-IWF, MME and UE requires MMEperforming encryption/decryption, integrity check on both direction withMTC-IWF and UE when each trigger and response is received. The largeamount of communication between UE and SCS will overload MME and NASlayer communication.

MTC-IWF, as the entrance element in the 3GPP network domain, authorizesSCS and its trigger request to a given UE, with support from HSS.MTC-IWF retrieves subscriber information and forwards the trigger fromSCS to UE.

However, the security over interface T5 has not been studied. MitMattack can happen over the interface for a roaming UE. On top of that, acompromised MTC-IWF can replay, discard or alter the trigger message.The UE, which is mutually authenticated to MME and HSS and has NASsecurity context established with MME, trusts messages received fromMME. Thus a fake trigger will be easily delivered to UE since MME doesnot perform any verification.

Therefore, it is necessary that UE and MTC-IWF have mutualauthentication; message integrity, authentication, authorization,confidentiality protection, replay protection. MTC-IWF should ensure thesecurity of trigger delivery, provide the proof when SCS isauthenticated and authorized to the network.

2. Proposal

We propose a new key hierarchy for UE and MTC-IWF to protect thecommunication between them, and present how the keys are derived andshared between the two ends, key management and also the extension tomobility case.

Communication between UE and MTC-IWF should have confidentiality andintegrity protection using the subkeys.

2.1 New Key Hierarchy

The key hierarchy constitutes of a root key and a pair ofconfidentiality and integrity protection subkeys. Using a pair ofsubkeys makes it easy to perform key management. When the subkeys areexpired or exposed, UE and MTC-IWF can simply derive another pair ofsubkeys from the root key they hold, instead of going all over again forkey derivation and allocation.

K_IWF is a root key that should be shared only between UE and MTC-IWF.It is used to derive a pair of subkeys K_IWFe and K_IWFi at UE andMTC-IWF separately. K_IWFe is the confidentiality key and K_IWFi is theintegrity key. The two subkeys are used for protecting the control planecommunication between UE and MTC-IWF.

2.2 Key Derivation At Both Network and UE

We propose in this document that the same root key K_IWF is derivedindependently at both MTC-IWF and UE.

HSS send Kasme to MTC-IWF over interface S6m, and MTC-IWF derives theroot key K_IWF from Kasme. The K_IWF should be stored in MTC-IWF andused for subkeys derivation.

Deriving the same key at different ends requires UE and MTC-IWF have thesame seed and parameters and use the same algorithm. Necessaryparameters for key derivation and algorithm identifier can be indicatedby HSS to UE. We propose a IWF SMC procedure, using the NAS SMCmechanism [TS33.401].

After MTC-IWF derived subkeys from the root key, it indicates theparameters and algorithms to UE in the IWF SMC message. The message isintegrity protected with integrity subkey K_IWFi.

In the same way as NAS SMC procedure, the UE should verify the integrityof the IWF security mode command message. If successfully verified, UEshould start uplink confidentiality and integrity security protection.UE sends the IWF security mode complete message to MTC-IWF withintegrity protection by using the integrity subkey K_IWFi it derived.

The MTC-IWF should check the integrity protection on the IWF SecurityMode Complete message using K_IWFi. The downlink ciphering at theMTC-IWF with the subkeys can start after receiving the IWF Security modecomplete message. The uplink deciphering at the MTC-IWF with the subkeyscan start after sending the IWF security mode command message.

If any verification of the IWF security mode command is not successfulin the UE, the UE should reply with a IWF security mode reject message.

The IWF SMC procedure can be an independent procedure or carried in NASSMC procedure, with the full message or necessary parameters only.

2.3 Key Management

2.3.1 Root Key Derivation and Renew

For root key K_IWF derivation, the same Key derivation function (KDF)for LTE/SAE key derivation [TS33.401] is used.

Root key should be renewed when a new Kasme is derived and sent toMTC-IWF. For handover between MMEs, there is no need to renew root key.For handover between MTC-IWF, a new root key should be derived.

2.3.2 Subkey Derivation

The subkeys K_IWFe and K_IWFi should be derived once after the root keyis derived. The subkeys derivation also uses the same KDF, with K_IWF asinput key. The truncation procedure as described in [TS33.401] can beused to obtain the subkeys K_IWFe and K_IWFi. Other input parametersinclude: counter, length of counter.

K_IWFe is a key, which shall only be used for the protection of trafficbetween UE and MTC-IWF with a particular encryption algorithm.

K_IWFi is a key, which shall only be used for the protection of trafficbetween UE and MTC-IWF with a particular integrity algorithm.

When there is a new root key derived, new subkeys should be derived fromthe new root key. Network can decide to derive new subkeys from the sameroot key according to its policy at any time.

Note that the present invention is not limited to the above-mentionedexemplary embodiment, and it is obvious that various modifications canbe made by those of ordinary skill in the art based on the recitation ofthe claims.

The whole or part of the exemplary embodiment disclosed above can bedescribed as, but not limited to, the following supplementary notes.

(Supplementary Note 1)

New IWF SMC procedure for establishing security association between UEand MTC-IWF.

(Supplementary Note 2)

Modification of NAS SMC to carry messages of IWF SMC.

(Supplementary Note 3)

MTC-IWF sends key derivation parameters (optional) and algorithm ID toUE in the IWF SMC message.

(Supplementary Note 4)

IWF SMC message is protected by integrity subkey.

(Supplementary Note 5)

UE derives K_iwf and subkeys, verify the received IWF SMC message withthe derived integrity subkey.

(Supplementary Note 6)

UE sends IWF SMC Complete message to MTC-IWF, integrity protects themessage with the integrity subkey UE has derived.

(Supplementary Note 7)

MTC-IWF performs integrity verification of IWF SMC Complete with theintegrity subkey it derived.

(Supplementary Note 8)

UE sends IWF SMC Reject message if the verification fails.

(Supplementary Note 9)

MTC-IWF indicates to HSS that the SCS initiated communication to a givenUE, with msg type=trigger and UE ID inserted in the SubscriberInformation Request.

(Supplementary Note 10)

Root key derivation parameter provision:

-   -   1) UE sends root key K_iwf derivation parameters in NAS message        to network.    -   2) HSS sends K_iwf derivation parameters to MTC-IWF, by re-using        Subscriber Information Response message or a new message of        Update Subscriber Information.    -   3) MTC-IWF sends K_iwf derivation parameters to HSS, for example        in Subscriber Information Request message.

(Supplementary Note 11)

HSS or MME sends MTC-IWF the algorithm ID that they used to deriveK_iwf.

(Supplementary Note 12)

HSS sends key derivation parameters and algorithm ID (optional) to MME.

(Supplementary Note 21)

A communication system comprising:

-   -   an MTC (Machine-Type-Communication) device; and    -   a network relaying traffic between the MTC device and a server        that can communicate with the MTC device,    -   wherein the network includes a first node that serves as a        gateway to the network for the server, and    -   the first node negotiates with the MTC device to establish        security association between the MTC device and the first node        itself.

(Supplementary Note 22)

The communication system according to Supplementary note 21,

-   -   wherein the network further includes a second node that can        establish confidentiality and integrity protected connection        with the MTC device, and    -   the first node and the MTC device transfer messages for the        negotiation through the second node.

(Supplementary Note 23)

The communication system according to Supplementary note 22,

-   -   wherein the MTC device sends, to the network that can be        confidential and integrity protected, parameters for the network        to derive a root key, and the root key is used for deriving at        least a subkey to check the integrity of messages transferred        between the MTC device and the first node.

(Supplementary Note 24)

The communication system according to Supplementary note 21 or 22,

-   -   wherein the first node sends an algorithm identifier to the MTC        device,    -   the algorithm identifier instructs the MTC device to select one        of algorithms for deriving a root key, and    -   the root key is used for deriving at least a subkey to check the        integrity of messages transferred between the MTC device and the        first node.

(Supplementary Note 25)

The communication system according to Supplementary note 24, wherein thefirst node further sends, to the MTC device, parameters for the MTCdevice to derive the root key.

(Supplementary Note 26)

The communication system according to Supplementary note 24 or 25,wherein the first node protects the message with the subkey.

(Supplementary Note 27)

The communication system according to Supplementary note 26, wherein theMTC device derives the root key and the subkey, and verifies the messagewith the derived subkey.

(Supplementary Note 28)

The communication system according to Supplementary note 27,

-   -   wherein upon succeeding in the verification, the MTC device        sends to the first node a response message indicating the        success, and    -   the MTC device protects the response message with the derived        subkey upon sending the response message.

(Supplementary Note 29)

The communication system according to Supplementary note 28, wherein thefirst node verifies the response message with the subkey.

(Supplementary Note 30)

The communication system according to any one of Supplementary notes 27to 29, wherein upon failing in the verification, the MTC device sends tothe first node a response message indicating the failure.

(Supplementary Note 31)

A node that is included in a network relaying traffic between an MTCdevice and a server being able to communicate with the MTC device, andthat serves as a gateway to the network for the server, the nodecomprising:

-   -   negotiation means for negotiating with the MTC device to        establish security association between the MTC device and the        node itself.

(Supplementary Note 32)

The node according to Supplementary note 31, wherein the negotiationmeans is configured to transfer messages for the negotiation to the MTCdevice through a different node that is included in the network and thatcan establish confidentiality and integrity protected connection withthe MTC device.

(Supplementary Note 33)

The node according to Supplementary note 31 or 32, wherein thenegotiation means is configured to send an algorithm identifier to theMTC device, the algorithm identifier instructing the MTC device toselect one of algorithms for deriving a root key, the root key beingused for deriving at least a subkey to check the integrity of messagestransferred between the MTC device and the node.

(Supplementary Note 34)

The node according to Supplementary note 33, wherein the negotiationmeans is configured to further send, to the MTC device, parameters forthe MTC device to derive the root key.

(Supplementary Note 35)

The node according to Supplementary note 33 or 34, wherein thenegotiation means is configured to protect the message with the subkey.

(Supplementary Note 36)

The node according to Supplementary note 35,

-   -   wherein the MTC device derives the root key and the subkey,        verifies the message with the derived subkey, and upon        succeeding in the verification, sends to the node a response        message indicating the success, the response message being        protected with the derived subkey,    -   wherein the negotiation means is configured to verify the        response message with the subkey.

(Supplementary Note 37)

The node according to any one of Supplementary notes 31 to 36,comprising an MTC-IWF (MTC Inter-Working Function).

(Supplementary Note 38)

An MTC device that communicates with a server through a network relayingtraffic between the MTC device and the server, the MTC devicecomprising:

-   -   negotiation means for negotiating, with a first node that is        included in the network and that serves as a gateway to the        network for the server, to establish security association        between the MTC device and the node.

(Supplementary Note 39)

The MTC device according to Supplementary note 38, wherein thenegotiation means is configured to transfer messages for the negotiationto the first node through a second node that is included in the networkand that can establish confidentiality and integrity protectedconnection with the MTC device.

(Supplementary Note 40)

The MTC device according to Supplementary note 39, wherein thenegotiation means is configured to send, to the network that can beconfidential and integrity protected, parameters for the network toderive a root key, the root key being used for deriving at least asubkey to check the integrity of messages transferred between the MTCdevice and the first node.

(Supplementary Note 41)

The MTC device according to Supplementary note 38 or 39, wherein thenegotiation means is configured to receive an algorithm identifier fromthe first node, the algorithm identifier instructing the MTC device toselect one of algorithms for deriving a root key, the root key beingused for deriving at least a subkey to check the integrity of messagestransferred between the MTC device and the first node.

(Supplementary Note 42)

The MTC device according to Supplementary note 41, wherein thenegotiation means is configured to further receive, from the first node,parameters for the MTC device to derive the root key.

(Supplementary Note 43)

The MTC device according to Supplementary note 41 or 42,

-   -   wherein the first node protects the message with the subkey,    -   wherein the negotiation means is configured to derives the root        key and the subkey, and to verify the message with the derived        subkey.

(Supplementary Note 44)

The MTC device according to Supplementary note 43, wherein uponsucceeding in the verification, the negotiation means is configured to:

-   -   protect, with the derived subkey, a response message indicating        the success; and    -   send the response message to the first node.

(Supplementary Note 45)

The MTC device according to Supplementary note 43 or 44, wherein uponfailing in the verification, the negotiation means is configured to sendto the first node a response message indicating the failure.

(Supplementary Note 46)

A method of controlling operations in a node that is included in anetwork relaying traffic between an MTC device and a server being ableto communicate with the MTC device, and that serves as a gateway to thenetwork for the server, the method comprising:

-   -   negotiating with the MTC device to establish security        association between the MTC device and the node.

(Supplementary Note 47)

A method of controlling operations in an MTC device that communicateswith a server through a network relaying traffic between the MTC deviceand the server, the method comprising:

-   -   negotiating, with a first node that is included in the network        and that serves as a gateway to the network for the server, to        establish security association between the MTC device and the        node.

This application is based upon and claims the benefit of priority fromJapanese patent application No. 2013-002981, filed on Jan. 10, 2013, thedisclosure of which is incorporated herein in its entirety by reference.

REFERENCE SIGNS LIST

10 MTC UE

11, 21 NEGOTIATION UNIT

20 MTC-IWF

30 MME/SGSN

40 HSS

50 SCS

1. A communication system comprising: an MTC-IWF (MTC(Machine-Type-Communication) Inter-Working Function); and a UE (UserEquipment), wherein the MTC-IWF stores a master key, derives subkeys forconfidentiality and integrity protection, and informs the UE about analgorithm for key derivation, wherein the UE derives, by using thealgorithm, the master key and the subkeys such that the UE shares thesame master key and the same subkeys with the MTC-IWF, wherein securityassociation is established between the UE and the MTC-IWF by using theshared master key and subkeys.
 2. The communication system according toclaim 1, further comprising: an HSS (Home Subscriber Server) thatderives the master key and sends the master key to the MTC-IWF.
 3. Thecommunication system according to claim 2, wherein the MTC-IWF storesthe master key received from the HSS.
 4. The communication systemaccording to claim 1, wherein the MTC-IWF derives the subkeys from themaster key.
 5. The communication system according to claim 1, whereinthe informing of the algorithm rides on NAS SMC (Non-Access StratumSecurity Mode Command).
 6. The communication system according to claim5, further comprising: an MME (Mobility Management Entity) that carriesa NAS SMC message to the UE, wherein the NAS SMC message includes an IWFSMC message for informing the UE about the algorithm.
 7. An MTC-IWFconfigured to store a master key, derive subkeys for confidentiality andintegrity protection, and inform a UE about an algorithm for keyderivation to cause the UE to derive the master key and the subkeys suchthat the UE shares the same master key and the same subkeys with theMTC-IWF, wherein security association is established between the UE andthe MTC-IWF by using the shared master key and subkeys.
 8. The MTC-IWFaccording to claim 7, further configured to receive and store the masterkey from an HSS.
 9. The MTC-IWF according to claim 7, further configuredto derive the subkeys from the master key.
 10. The MTC-IWF according toclaim 7, further configured to send an IWF SMC message for informing theUE about the algorithm to an MME that carries a NAS SMC message to theUE.
 11. A UE configured to derive, by using an algorithm for keyderivation informed from an MTC-IWF, a master key and subkeys forconfidentiality and integrity protection such that the UE shares themaster key and the subkeys with the MTC-IWF, wherein securityassociation is established between the UE and the MTC-IWF by using theshared master key and subkeys.
 12. The UE according to claim 11, furtherconfigured to derive the subkeys from the master key.
 13. The UEaccording to claim 11, further configured to receive from an MME a NASSMC message that includes an IWF SMC message for informing about thealgorithm. 14-15. (canceled)
 16. A method of securing MTC communication,the method comprising: storing, by an MTC-IWF, a master key; deriving,by the MTC-IWF, subkeys for confidentiality and integrity protection;informing, by the MTC-IWF, a UE about an algorithm for key derivation;and deriving, by the UE using the algorithm, the master key and thesubkeys such that the UE shares the same master key and the same subkeyswith the MTC-IWF, wherein security association is established betweenthe UE and the MTC-IWF by using the shared master key and subkeys. 17.The method according to claim 16, further comprising: deriving, by anHSS, the master key; and sending, by the HSS, the master key to theMTC-IWF.
 18. The method according to claim 17, further comprising:storing, by the MTC-IWF, the master key received from the HSS.
 19. Themethod according to claim 16, wherein the MTC-IWF derives the subkeysfrom the master key.
 20. The method according to claim 16, wherein theinforming of the algorithm rides on NAS SMC.
 21. The method according toclaim 20, further comprising: carrying, by an MME, a NAS SMC message tothe UE, wherein the NAS SMC message includes an IWF SMC message forinforming the UE about the algorithm.